A summary of the diagnostic steps and the "Stupid Subnetting Strategy" required to bypass a severe route-injection bug in the macOS Cloudflare WARP client on Apple Silicon.
Goal: Route a local private network (192.168.1.0/24) through a Cloudflare Tunnel via the WARP client.
The Issue: While the iOS client worked flawlessly, the macOS daemon silently dropped the /24 route from the OS routing table. When attempting to fix it by breaking the subnet into halves (e.g., two /25s or /26s), an auto-summarization bug in the client caused it to improperly deduplicate and drop adjacent blocks, leaving massive gaps in network coverage.
These commands were used to isolate whether the issue was in the Cloudflare Dashboard, the Tunnel, or the macOS OS level.
1. Check how macOS is routing a specific IP (shows if WARP is intercepting):
route get 192.168.1.13
Look for the "interface:" line. "en0" means bypass; "utunX" means WARP has it.
2. View the full routing table filtered for the target subnet:
netstat -nr -f inet | grep 192.168
3. Force a manual route injection (proves the tunnel works if the client fails):
sudo route add -net 192.168.1.0 -netmask 255.255.255.0 -interface utun10
4. Hard reset the WARP daemon's cache:
warp-cli disconnect
warp-cli registration delete
To bypass the client's buggy summarization engine, the 192.168.1.0/24 network had to be fragmented into specific, mismatched chunks to force macOS to accept them as distinct rules.
| CIDR Block to Include | IP Range Covered | Status |
|---|---|---|
| 192.168.1.0/25 | 0 – 127 | Injected |
| 192.168.1.128/28 | 128 – 143 | Injected |
| 192.168.1.144/30 | 144 – 147 | Injected |
| 192.168.1.148/32 | 148 | Forced Host Route |
| 192.168.1.149 | 149 | The Cursed Void |
| 192.168.1.150/32 | 150 | Forced Host Route |
| 192.168.1.151/32 | 151 | Forced Host Route |
| 192.168.1.152/30 | 152 – 155 | Injected |
| 192.168.1.156/30 | 156 – 159 | Injected |
| 192.168.1.160/27 | 160 – 191 | Injected |
| 192.168.1.192/26 | 192 – 255 | Injected |
If you absolutely must access the cursed IP (192.168.1.149) which the WARP daemon refuses to parse, you can manually inject it into the routing table at the OS level using this command (replace utun10 with your active WARP interface):
sudo route add -host 192.168.1.149 -interface utun10
* Note: Manual routes are cleared upon system restart.